Allow generics in runtime expressions#2302
Conversation
Current coverage is 83.13% (diff: 100%)@@ master #2302 diff @@
==========================================
Files 72 72
Lines 19032 19036 +4
Methods 0 0
Messages 0 0
Branches 3917 3919 +2
==========================================
+ Hits 15814 15826 +12
+ Misses 2618 2611 -7
+ Partials 600 599 -1
|
|
Looks great, no need for Jukka to review. |
Fixes python/typing#303. See also python/mypy#2302 (which removes the restriction from mypy). As a motivation, in Python one always can substitute expressions, so that if ``IntNode = Node[int]; IntNode()`` works, then it is reasonable to also allow ``Node[int]``, but say that the first way is preferred.
|
I just got a crash when running this on some code of ours. I'm still trying to distill the code that triggers it into something small, but here's the traceback: The line triggering it has: # This magical WizkitStrings metaclasss confuses mypy
return self.account.render_string(WizkitStrings[string], # type: ignore
flip_role=flip_role, max_len=max_len, **kw)The class WizkitStrings inherits from another class which has a metaclass defining |
|
@gvanrossum |
|
I figured it was something like that. If you can come up with a test and a fix for that test, a separate PR would be great. |
|
@gvanrossum Sorry, it is more complex than I thought. I still could not reproduce this crash. I will continue to look for a good test for this. |
As discussed in python/typing#303 generics in ``typing.py`` are now cached and are therefore much faster at runtime than before. Here I propose (and it looks like Guido is not against this) to allow generic types as runtime expressions.
As discussed in python/typing#303 generics in
typing.pyare now cached and are therefore much faster at runtime than before. Here I propose (and it looks like Guido is not against this) to allow generic types as runtime expressions.@JukkaL Please take a look.